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ABSTRACT 



Current software development methodologies have proven to be ineffective for 
meeting the rising demand for fast production of reliable software for hard real-time 
computer systems. A computer-aided, rapid prototyping system (CAPS) based on a 
Prototype System Description Language (PSDL) and a set of software tools including 
an Execution Support System (ESS), has been proposed by other research and provides 
a promising and cost effective alternative to the traditional development life cycle of 
these systems. 

This study proposes a four function design for the dynamic scheduler of the CAPS 
ESS. This design includes a method for invoking processes for the ESS static scheduler 
and translator, a scheduling algorithm for the scheduling of the prototype's non-time 
critical processes, and a method for error and interrupt handling during prototype exe- 
cution. 
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I. INTRODUCTION 



A. BACKGROUND 

Increasing demand for rapid development of high quality software has risen to the 
point that significant improvements must be made to current software development 
methodologies. This is because these methods do not produce software fast enough, nor 
do they result in software products of sufficient quality. This is particularly true for 
development of software for hard real-time systems. A hard real-time system is one in 
which tasks have deadlines that must be met, otherwise severe consequences may result. 
Many Command, Control and Communications (C3) Systems are examples of such 
systems. 

Production of hard real-time systems that support communications requirements 
within the area of C3 are particularly challenging to software developers. One reason 
for this is that communications systems arc usually subject to very stringent real-time 
requirements. For example, receiving and processing data from remote sensors may 
need to occur in the micro or millisecond timeframe. Another reason, often inherent to 
defense systems, is that communications software (as well as other types of software) 
must be interoperable across a wide variety of hardware and software environments. 
This is exemplified by the fact that equipment from multiple vendors (utilizing proprie- 
tary or incompatible protocols), and obsolete, poorly documented systems must function 
together in support of various operational requirements. Furthermore, maintenance 
considerations across these diverse environments mtroduce an additional level of diffi- 
culty for software developers because the interoperability of these systems must be 
maintained when inconsistencies are reconciled or when upgrades are applied. 

One method for meetuig these challenges, and the increased demand for rapid sys- 
tem development, is rapid prototyping. A prototype is an executable model or pilot 
version of the intended system which is used as an aid in analvsis and design rather than 
as production software to be delivered to the user. Rapid prototyping is the con- 
struction activity which creates this executable model. This technique has been found 
to be effective for clarifying user requirements and eliminatuig the large amount of 
wasted effort currently spent on developing software to meet incorrect or inappropriate 
requirements in traditional software life cycles. [Ref 1: p. 1] 



Rapid construction of executable prototypes for hard real-time systems would be 
greatly enhanced through the use of a computer-aided design system. One such system 
proposed by [Ref 2| and [Ref 3] is the Computer Aided Prototyping System (CAPS). 
CAPS presents an alternative to the traditional software development life-cycle and is 
based on a Prototype System Description Language (PSDL) and a prototyping meth- 
odology. 

The CAPS prototyping methodology, as illustrated by Figure 1 on page 3 is an it- 
erative process. The software developer constructs a prototype based on user require- 
ments, then the developer and user examine the executable prototype together. During 
this examination, adjustments are made and the prototype is modified until both the user 
and developer agree that the user's requirements will be met. 

Prototype System Description Language (PSDIT was developed in conjunction with 
this methodology because a language for supporting rapid prototyping of large real-time 
systems has different requirements from general purpose programming or specification 
languages. PSDL contains several unique features which meet these requirements. For 
example: 

PSDL is based on a simple computational model which limits and exposes the inter- 
action between system modules thus promoting eflectivc modularization of the pro- 
totype. 

PSDL contains basic data, control, and function abstractions which allow specifica- 
tion and representation of the intended system most important for creation and exe- 
cution of the prototype. 

Appendix A is an e.xample of a PSDL prototype as it appears in [Ref 4; pp. 27-40] 
and Appendix B is a summary of PSDL grammar and language conventions from [Ref 
1: pp. 54-56], provided as additional clarification for this example. This prototype was 
developed to model a simple system for treating brain tumors using hyperthermia and 
was structured to meet the following requirements: 

1. Shutdown: Microwave power must drop to zero within 300 milliseconds of turning 
off the treatment switch. 

2. Temperature Tolerance: After the system stabilizes, the temperature must be kept 
between 42.4 degrees C. and 42.6 degrees C. 

3. Maximum Temperature: The temperature must never exceed 42.6 degrees C. 

4. Startup Time: 'fhe system must stabilize within 5 minutes of turning on the treat- 
ment switch. 

5. Treatment Time: The system must shut down automatically when the temperature 
has been above 42.4 degrees C. for 45 minutes. 
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Figure 1. PROCESS OF REQUIREMENTS DETERMINATION AND VALI- 
DATION BY PROTOTYPING 



[Ref. 4: pp. 26-27] 

A prototype is created in PSDL using networks of operators communicating via 
data streams. A data stream is a communications link connecting exactly two operators, 
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a producer (one which produces a data value), and a consumer (one which consumes 
or receives the data value). Data streams also carr>^ data values which represent EX- 
CEPTION conditions. PSDL exceptions are values of a built in abstract data type called 
EXCEPTION. This type has operations for creating an exception with a given name 
(e.g. "overflow"), and for detecting whether a value is normal (i.e. belongs to some data 
type other than EXCEPTION). [Ref. 4: p. 13] 

The other PSDL data types include the unalterable subset of the built-in types of the 
Ada® programming language (Ada® is a registered trademark of the United States 
Government, Ada Joint Programming Office), user defined abstract types, the special 
type TIME (the other special type being EXCEPTION as previously described), and the 
types that can be built using the immutable type constructors of PSDL. The PSDL type 
constructors were chosen to provide powerful data modeling facilities with a small set 
of semantically independent structures. [Ref 4; p. 15] 

Each data type or operator is cither composite or atomic. Composite operators are 
implemented by decomposing them into networks of more primitive operators (using 
PSDL). Atomic operators are created by retrieving an implementation from a software 
base containing reusable software components implemented in an underlying program- 
ming language. 

In in order to meet timing constraints of the prototype under construction, an op- 
erator can either be periodic, or sporadic. A PSDL operator is periodic if a period has 
been specified for it explicitly, or if it inherits a period from a higher level in the de- 
composition of the hierarchical prototype. If neither of these conditions are true, then 
the operator is sporadic or data driven. A sporadic operator is e.xecuted (triggered by) 
the arrival of a new data value, possibly at irregular time intervals, whereas periodic 
operators are triggered or executed at regular time intervals (specified periods). A peri- 
odic operator must be completed sometime between the beginning of the period and a 
deadline (which defaults to the end of the period). Periodic operators have traditionally 
been the basis for the design of most real-time systems, but the importance of data 
driven operators for this type of system is also beginning to be recognized since event 
driven in terms of informal software design methodology, or interrupt driven in terms 
of hardware language, can be treated in this category. [Ref. 4: pp. 6-13] 

The foregoing features make PSDL particularly appropriate I'or real-time system 
design. Its structure is highly suitable for multiple modifications during prototyping it- 
erations because it consists of basic building blocks that allow descriptions of ab- 
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stractions through a top-down design based on data flow. Additionally, the formal 
structure of PSDL for specifying the user's real-time constraints provides a basis for 
automating the production code to an underlying programnoing language e.g. Ada®. The 
execution of the PSDL prototype also verifies that the design of an embedded system (a 
system that is part of a larger system such as a guidance computer on a missile), within 
given timing constraints for the prototype components, will interact with its environment 
in a way that meets the timing constraints of the entire system. [Ref 1: p. 3] 

The other components of the CAPS are user interfaces, including a syntax directed 
editor with graphics capability (for speeding up design entry and preventing syntax er- 
rors), an execution support system for demonstrating and measuring prototype behavior 
and for performing static analyses of the prototype design, a software design manage- 
ment system for retrieving and adapting reusable software components, and a compo- 
nent base which functions as a repository for the reusable components [Ref 2: p. 9]. 
The reusable software components in the software base can be written in any general 
purpose programming language (provided that PSDL specifications for each module are 
included). Figure 2 on page 6 illustrates the CAPS architecture. 

For purposes of simplification, and because of its required use within the Depart- 
ment of Defense as a standard development language, Ada® has been chosen for imple- 
menting both the reusable components in the software base and the PSDL execution 
support environment. Ada® is a powerful programming language that provides unique 
features not found in other languages. These include exception handling, inter-task 
communication, (both of which will be demonstrated to be particularly important to the 
CAPS execution support environment), and facilities such as generic packages (reusable 
software components). Several predefined generic units are already included as part of 
the Ada® language definition e.g. CALENDAR which can be used to provide date and 
time information. [Ref 5: pp. 33-34] 

An Ada® program is composed of one or more program units, most of which may 
be separately compiled. Program units consist of subprograms, tasks, packages, and 
generic units. A subprogram is either a procedure or a function. A procedure specifies 
a sequence of actions and is invoked by a procedure call statement. A function specifics 
a sequence of actions and also returns a value called the result; therefore a function call 
is an expression. A task, on the other hand, defines an action that is logically executed 
in parallel with other tasks. A task may be implemented on a single processor, a multi- 
processor, or a network of computers. A package is a collection of computational re- 
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Figure 2. CAPS Architecture 

sources, which may encapsulate data types, data objects, subprograms, tasks, or even 
other packages. Its primary purpose is to express and enforce a user's logical ab- 
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stractions within the language. A generic unit is a "template" or "pattern" for subpro- 
grams and packages and serves as the primary mechanism for building reusable software 
components. Use of a generic unit within an Ada® program is termed instantiation. 

All Ada® program units generally have a similar two-part structure, consisting of a 
specification and a body. The specification identifies the information visible to the client 
(interface) of that program unit and the body contains the unit implementation details. 
[Ref 5: pp. 55, 554] 

Ironically, it is some of these same attractive features of the language that make Ada® 
too complex and hence, too impractical, for its direct use in the rapid prototyping envi- 
ronment. PSDL however has incorporated many of the desirable features of Ada® while 
eliminating the associated complexity. The abstractions of PSDL allow a system de- 
signer to express ideas at the specification and design level rather than at the program- 
ming language level. This substantially reduces the need for consideration of lower-level 
details and flow control that would be required if the prototype was developed using Ada® 
directly. 

B. OBJECTIVES 

The primary focus of this study is the conceptual development of one component 
of the execution support system of the CAPS, the dynamic scheduler. As it is currently 
proposed, the execution support system will be comprised of three components, a 
translator, a static scheduler, and a dynamic scheduler. The translator is developed in 
[Ref 6] and the static scheduler is developed in [Ref 7] and [Ref S]. A secondary, but 
equally important focus is the interfacing of the dynamic scheduler with these other two 
components. 

Within the CAPS execution support environment each of these components will 
perform several functions as shown in Figure 3 on page 8. The translator has four main 
purposes: 

1. To augment the PSDL code 

2. To implement PSDL data streams 

3. To implement PSDL conditionals (triggering conditions) 

4. To implement PSDL timers (accomplished through the use of a standard library 
package which communicates with a hardware clock and is included in any proto- 
type that uses timers) 
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Figure 3. COMPONENTS OF THE CAPS EXECUTION SUPPORT SYSTEM 



The static scheduler analyzes the real-time constraints declared in the PSDL prototype 
and attempts to fmd a static schedule meeting the constraints of the time critical opera- 
tors of the prototype under construction. 

The dynamic scheduler performs four major functions for the CAPS execution sup- 
port system. The first function, which is to act as a "run-time executive", is of particular 
importance to the other two CAPS components. As the run-time executive, the dynamic 
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scheduler will invoke the static scheduler, and it will invoke buffer pre-loading proce- 
dures required by the translator for implementation of data streams. Two other func- 
tions include exception handling and hardware or operator interrupt handling that may 
occur during prototype execution. 

The fourth and perhaps most important function of the dynamic scheduler will be 
the scheduling and execution of the PSDL operators which are not time critical (i.e. do 
not have real-time constraints). This schedule will be constructed and executed during 
prototype execution using "spare processing time" created as a result of early completion 
of time critical operators by the static scheduler. Because PSDL assumes that time 
constraints of critical operators are absolute when given, the static scheduler allocates 
processing resources based on vvwst case or maximum execution times. On the average, 
these worst case processor loads tend to be rare. When a time-critical operator or group 
of operators finishes executing before this worst-case time allocation, the static scheduler 
can "transfer" control of processor resources to the dynamic scheduler in order to utilize 
the resulting spare capacity. 

The requirement for e.xplicitly passing control to the dynamic scheduler when the 
static scheduler reaches an idle state is necessary because the Ada® language does not 
have features for determining when a task or process with an undefined priority should 
be executed [Ref 5; p. 282]. Once control of processing resources is passed to the dy- 
namic scheduler, spare processing capacity can be allocated among the non-time critical 
operators based on a scheduling process that is not restricted by the requirement for 
meeting real-time constraints. 

C. BENEFITS OF THIS STUDY 

The benefits to be derived from this study are twofold. The first of these is that 
development of a dynamic scheduler for the proposed CAPS aids in meeting the need for 
development of a rapid prototyping tool. An effective CAPS would result in significant 
improvements and cost savings in the development of hard real-time software systems 
which support C3 mission requirements as well as software development for other DOD, 
and private industry applications. 

The second benefit is the focus placed on more effective processor utilization as a 
result of scheduling non-time critical tasks or processes during slack or spare processing 
periods. Previous research in the area of real-time system scheduling has greatly em- 
phasized, and rightly so, the requirement for meeting the real-time constraints of a sys- 
tem or network of systems. This particular emphasis has minimized the importance of 
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processor under-utilization which olten occurs as a result of ensuring that real-time 
constraints are met. The problem of under-utilization is wasteful and could become 
quite costly if it is allowed to occur on a regular basis. Design and interface of a dy- 
namic scheduler for use within the rapid prototyping environment may provide a viable 
solution to this problem. 

D. OVERVIEW 

The remainder of this study is described by the following overview; 

A survey of the background and development of scheduling problems and algorithms 

Development of a dynamic scheduler based on concepts provided by this survey and 
the use of Ada® as an implementation language 

A summary which describes the questions answered by this study, future questions or 
design areas that need to be addressed, and a brief description of a communications 
system for demonstrating the feasilibity of the CAPS as a computer-aided design tool. 
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II. BACKGROUND AND DEVELOPMENT OF SCHEDULING 

ALGORITHMS 



A. THE SCHEDULING PROBLEM 

A scheduling algorithm provides a set of rules that determine a process or group of 
processes to be executed at a particular point in time on a process control computer 
system or for a network of systems [Ref 9: p. 194]. Criteria which have historically been 
used to generate process schedules include maximizing process flow (i.e. minimizing tlie 
elapsed time for the entire processing sequence), or minimizing the maximum lateness 
(lateness is defined to be the difference between the time a process is completed and its 
deadline when the deadline is missed) [Ref 10: p. 112]. 

Development of an algorithm which focuses on maximizing process flow is applica- 
ble to the problem of scheduling PSDL operators without real-time constraints since 
optimal use of idle processing time is an objective of the CAPS dynamic scheduler. 
However, muiimizing lateness is not a consideration for the dynamic scheduler since 
operators which are not time critical don't have deadlines to meet. For meeting the re- 
quirements of the CAPS static scheduler, neither of these criteria is important partic- 
ularly since operators with real-time constraints are by definition not allowed to be late. 
The criteria wliich are important for process scheduling within the CAPS execution 
support environment include meeting the deadlines of operators with real-time con- 
straints, ensuring that no data loss occurs, and making optimal use of spare processing 
resources. Clearly, finding or developing scheduling algorithms which optimize this set 
of criteria presents an interesting and difficult problem. 

Another previously defined [Ref 9; pp. 194-199] consideration for generating process 
schedules and developing scheduling algorithms is based on precedence or priority of 
processes to be executed. Two primary priority classifications are static priority and 
dynamic priority. In the first case, priorities and start times of processes are known in 
advance and is not expected to change during execution [Ref 9: p. 194]. Within the 
CAPS, a scheduling algorithm based on a static priority scheme w’ill be used by the static 
scheduler to create a schedule that meets the timing and precedence relationship re- 
quirements for the time critical operators. In the second case, priorities of processes 
change from time to time, depending upon certain execution conditions (e.g. the avail- 
ability of idle processing capability) [Ref 9: p. 194]. This priority scheme will be used 



by the CAPS dynamic scheduler to schedule non-time critical PSDL operators and to 
perform other functions during prototype execution such as exception or interrupt han- 
dling. 

B. SCHEDULING METHODS 

The requirement for different types of schedulers and scheduling algorithms has been 
examined in a myriad of research. Most of this work has been directed at the problem 
of scheduling processes or operations which must meet critical or real-time deadlines, 
but these elTorts also have relevance to the problem of scheduling processes which don't 
have real-time constraints. The primary reason for this is that while an individual 
process (e.g. a PSDL operator) may not have a time critical deadline, scheduling of the 
process or group of processes should be completed within a predetermined block of idle 
processing time in order to make optimal use of this spare capacity. The following ex- 
amination and description of scheduling research provides a basis for designing a dy- 
namic scheduler to meet this objective. 

1. DECOMPOSITION STRATEGIES 

A primary consideration in solving the scheduling problem is how to decompose 
a set of operations (computations) mto a schedule which meets the real-time constraints 
of a given system or program. Mok in [Ref. 11 ; pp. 125-133] proposes three strategies 
for the decomposition of a set of computations based on timing constraint specifications. 
Each of these strategies uses a "graph" model to describe the set of computations and a 
"process" model to describe the output generated by the translation of the set of com- 
putations. 

The graph model consists of a communications graph, a task graph, and a set 
of timing constraints. Timing constraints are represented by the e.xpression (t, t + d) 
where t is the start time for a process, d is its deadline, and t + d the interval or period 
in which the process is executed. A task graph defines the precedence relationship 
among computational events that must occur in order to satisfy a given timing con- 
straint. It is composed of "nodes" and "edges" which respectively denote corresponding 
functional elements and transmission paths for data in the communications graph [Ref. 
11: p. 126). The objective of this structure is to ensure that data Qow requirements are 
met. This is also one of the objectives of the PSDL structure, (the other objective being 
that real-time constraints will be met). PSDL is based on these concepts with an oper- 
ator representing a "functional element" of the language, and with data streams repres- 



enting communications paths which transmit or exchange information between 
operators. 

The Process Model is generated by the translation of the time-critical compu- 
tation requirements of a real-time system. The result of the translation is a set of time- 
critical concurrent processes [Ref 11; p. 125|. The translation that results in the process 
model is analogous to the generation of the of the CAPS static schedule since this 
schedule provides the means for meeting a system's real-time constraints. 

Based on these concepts, the first strategy to be discussed is Decomposition by 
Critical Timing Constraints. This strategy works in the following manner. For a partic- 
ular program, periodic and sporadic processes are created to meet given timing con- 
straints. The period and deadhne attributes of a process are set to the corresponding 
parameters of the timing constraint (t, t + d). These processes may have functional el- 
ements in common so a monitor is created to ensure mutual exclusion on the execution 
of any program element called by two or more processes. When a program created in 
this manner is executed, each process is executed according to its specified timing con- 
straints even though this may result in duplicate execution of certain computational 
events. [Ref 1 1: p.l2S] 

This strategy works fairly well on single processor with any scheduling discipline 
as long as the processor doesn't idle while there is an activated process [Ref 11; p. 128]. 
The disadvantages associated with the use of this strategy are the duplication of some 
computations within processes that have compatible timing constraints and the com- 
munications costs involved for enforcing mutual exclusion. 

A second strategy. Decomposition by Centralized Concurrency Control works 
in the following way. Periodic timing constraints that are compatible with one another 
are grouped together. Two periodic timing constraints are compatible if their deadlines 
(d) are equal, (e.g. dl = d2), if their task graphs have some nodes in common, and if the 
period (p) of one can divide, or be divided by the period of the other (pl/p2 or p2/pl). 
The compatibility relation partitions the periodic timing constraints into a set of equiv- 
alence classes. For each equivalence class, a periodic process of compatible periodic 
timing constraints is created, and a sporadic process is created for each asynchronous 
timing constraint. 

In general, this strategy improves efTiciency two ways. First, by merging the 
computation of compatible timing constraints into a single process, redundant compu- 
tation can be eliminated. Second, since concurrency control is being centralized, proc- 
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esses tend to be independent of one another and the interprocess communication 
overhead required for concurrency control will be smaller. One disadvantage associated 
with this strategy is that attempts to merge compatible timing constraints into a single 
program by eliminating as much redundant computation as possible, may not yield the 
shortest program possible. A second disadvantage associated with this strategy is its 
complexity, which makes it more difficult to understand and to modify when changes 
are required. [Ref 11: pp. 129-130] 

The third strategy is Decomposition by Distributing Concurrency Control. In 
this strategy, a periodic process will be created for each node (functional element) in the 
communication graph. Since a functional element F, may occur in two or more task 
graphs, the periodic process created for F will be assigned a period attribute equal to the 
smallest period among the periodic timing constraints in which F occurs. When a peri- 
odic process PF, is activated, it first synchronizes with an appropriate set of processes 
preceded by it. A sporadic process is created for each asynchronous timing constraint 
as before. If a functional element occurs in both a periodic timing constraint and an 
asynchronous timing constraint, then a monitor is created to enforce mutual exclusion 
on the execution of the corresponding program element. [Ref 11: p. 131] 

Use of this strategy results in the following advantages. By assigning a separate 
process to each functional element, an attempt is made to maximize the computation 
that can be performed in parallel. Redundant computation is reduced since task graphs 
of compatible timing constraints that contain the same functional elements are detected 
in the construction of the synchronization code for each periodic process. If as many 
processors are available as there are processes, then this strategy can accommodate a 
wider range of timing constraints than the other two strategies. The primary disadvan- 
tage with this approach is again one of complexity and the resultant modification diffi- 
culties its use implies. [Ref 1 1: p. 132] 

2. THREE PROCESS MODELS 

Another study by Mok [Ref. 12: pp. 5-17] develops three process models using 
various scheduling algorithms and techniques. These models are based on the idea that 
there is a need for an off-line scheduler and a run-time scheduler for meeting the periodic 
and sporadic timing constraints of most real-time systems. As defined by this work, the 
off-line scheduler examines the instance of a process, or system and creates a run-time 
scheduler together with a database for making scheduling decisions at run time. The 
run-time scheduler is the code for allocating resources in response to requests generated 
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at run time, e.g. timer or external device interrupts. A run-time scheduler is totally on- 
line if its decisions do not depend on prior knowledge of the future request-times of the 
processses. A run-time scheduler can also be clairvoyant, which means that it can pre- 
dict with absolute certainty, the future request times of all processes. A clairvoyant 
scheduler represents the best possible case though and is usually impossible to imple- 
ment in practice. And finally, a run-time scheduler is optimal if it always produces a 
feasible schedule whenever it is possible for a clairvoyant scheduler to do so. 

The first model described by this piece of research is the Independent Process 
Model. It was shown that two possible algorithms provided effective scheduling tech- 
niques for this model, the earliest deadline algorithm and least slack algorithm. The 
earliest deadline algorithm runs any ready process with the nearest deadline and the least 
slack algorithm runs any ready process which has the least slack time available before 
it will miss its current deadline. In both cases, ties are broken arbitrarily and the as- 
sumption is made that the scheduler can choose to preempt a process by any other ready 
process at integral time instants. 

Although both of these algorithms are effective, the preceding assumption il- 
lustrates why neither of them represents an optimal scheduling method. In order for 
these techniques to be optimal, the scheduler would have to be clairvoyant. For exam- 
ple, the position of an aircraft is updated by a periodic process which computes the X 
and Y coordinates from sensor measurements. A sporadic process may read the X value, 
be preempted by the tracking process, and then read a new Y value which is inconsistent 
with the original X value. Clairvoyaiicy implies that an exact prediction could be made 
as to when the sporadic process which updates the X value will occur, which is unlikely. 
A possible means for eliminating this inconsistency is to prevent processes from pre- 
empting one another, but enforcement of such a mutual exclusion constraint results in 
significant decreases in processing efficiency. [Ref 12: p. 7] 

A feasible, yet still not optimal, alternative to this approach is provided by the 
Deterministic Rendezvous Model. This model attempts to alleviate the problems asso- 
ciated with the Independent Process Model by using the earliest deadline algorithm with 
dynamically assigned (determined during execution) process deadlines, and through the 
implementation of an Ada®-like rendezvous primitive (communications instruction). 

The rendezvous primitive establishes synchronization and precedence relation- 
ships among executing processes. It operates on the same principle that is required for 
the establishment of certain data communications links. For example, if Process A 
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wishes to communicate or rendezvous with Process B, A executes a rendezvous primi- 
tive. A must then wait for B to execute a rendezvous which indicates that it is ready to 
exchange information or rendezvous with A. The precedence relationships among 
processes are created by the requirement that all the computation before the rendezvous 
primitive in each process must precede all the computation after the corresponding ren- 
dezvous primitive in the other process [Ref 12: p. 9). 

At run-time, this model works in the following way. Processes are grouped into 
scheduling blocks with each block initialized with a deadlme. During execution, the 
deadline of a scheduling block can be moved up if the block must precede another block 
which has a nearer deadline but which is not yet ready to run. The rendezvous primitive 
provides the required synchronization and precedence information which allows this 
scheme to vvork. It should be pointed out though that this primitive does not guarantee 
mutual exclusion for a scheduling block. It also cannot be used to establish communi- 
cations between a periodic process and a sporadic process since by definition, a periodic 
process must be executed regularly while a sporadic process may never be executed. 
[Ref 12: pp. 9-10] 

The third model differs only slightly from the Deterministic Rendezvous ap- 
proach. This model called the Kernelized Monitor, uses an operating system kernel as 
a monitor for enforcing mutual exclusion of processes during execution. Processor time 
is allocated only in uninterruptible quantums, say of size q, with q chosen to be bigger 
than the largest monitor. For simplicity, the required computation times for process 
scheduling is in exact multiples of q so that each process takes an integral number of 
quantums to execute. A process to be executed forms a chain of mini-scheduling blocks 
each of which requires a quantum (the basic time unit of processor allocation). These 
mini-scheduling blocks form a partial order imposed by the (intra and interprocess) 
precedence relationships and each is given a request-time and deadline. The mini- 
scheduling blocks are executed using the earliest dynamic deadline algorithm as previ- 
ously described in the discussion of the Deterministic Rendezvous .Model. 

One dilference between the execution of mini-scheduling blocks and the exe- 
cution of blocks created by the Deterministic Rendezvous approach is that preemption 
should only be allowed to occur after a mini-block has been allocated an integral number 
of time quantums. Another dilference is that between each chain of mini-scheduling 
blocks an interval called a "forbidden region" is included in in the schedule. The purpose 
of this interval is to create idle processing time during which a scheduler should not al- 
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locate a new quantum of processor time to any process so that a future deadline can be 
met. [Ref 12: pp. 10-11] 

3. EARLIEST DEADLINE-PREDECESSOR PRIORITY ALGORITHM 

Another research effort by Mok demonstrates the use of the earliest deadline 
algorithm in a slightly different way. This effort was directed at periodic real-time sys- 
tems where input data arrives at fixed rates, but otherwise there are no explicit timing 
constraints. Its application is also limited to uniprocessor environments. 

The Earliest Deadline-Predecessor Priority (ED-PP) scheduling procedure can 
be described by these steps. First, a very simple method (as compared to use of the 
rendezvous primitive) is used to determine precedence relationships among processes. 
Specifically, processes are ranked in a topological order of their corresponding functional 
elements in a graph model such that whenever two processes have the same deadline, 
higher priority is given to the process which appears earlier in the topological ordering 
(hence the name predecessor priority) [Ref. 13: p. 184], Next, a round robin scheduler 
is employed in the following way. Assume that a quantum (the previously detined time 
unit) is composed of infinitely many slices. A round robin scheduler allocates c/p slices 
of each quantum to each process P. Each P will be guaranteed to receive c quantuins 
of processor time in every period of length p, thus meeting its deadline. The above al- 
location can always be done because available processor time U is < = 1. [Ref. 13: 

p. 186] 

The round robin schedule is then transformed into the desired schedule by 
swapping time slices in the following maimer. At any quantum, let P be the process with 
the nearest deadline as chosen by the ED-PP scheduler. Then, swap as many slices of 
P from the next quantuins as needed to fill just the quantum under consideration. No 
process will miss its deadline since the deadline of p is the nearest. This swapping is re- 
peated one quantum at a time from the beginning of the schedule until the valid ED-PP 
schedule of desired length is obtained. [Ref 13: p. 186] 

4. THE RATE MONOTONIC SCHEDULING ALGORITHM 

This algorithm works in the following way. For a set of periodic tasks, a fixed 
priority is assigned to each task, with a higher priority being assigned to tasks with 
shorter periods. The rate monotonic algorithm is an optimal static priority algorithm in 
a uniprocessor environment with a set of n tasks with total utilization less than or equal 
to n(2'''’ — 1). When n becomes large, this bound approaches In 2 (approximately 70%). 
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One method for implementing this algoritlmi incorporates a "time-division 
multiplexing" scheme to schedule periodic tasks (processes). This approach is similar to 
the round robin scheduler used by the ED-PP algorithm. This is accomplished through 
the creation of a set of time division multiplex (TDM) slots and then "hand-packing" all 
the important tasks into them. This is typically done in the context of a cyclical execu- 
tive (the cyclical executive operates like the round robin scheduler), which generally uses 
few frequencies. The fastest cycle is usually called the major cycle and the slower ones 
are called minor cycles. The major cycle is assigned the highest priority. Given the 
highest priority, a major cycle with period P will be regularly given 1 slot every P units 
of time. This in effect creates a virtual processor with processing bandwidth 1/P. The 
period of the major cycle is determined by two factors. First period P must be short 
enough so that it can accommodate the highest frequency periodic tasks. Second, the 
major cycle must also acconmiodate tasks which have lower frequencies but are critical 
to the mission at hand, since the major cycle has the highest priority. A handcrafted 
table is then constructed to schedule both the high frequency tasks and the critical tasks 
over the virtual processor. The construction of the scheduling table often takes many 
iterations, over the adjustment of the period of the major cycle, the modification of the 
scheduling table and the optimization of the code of certain tasks. [Ref. 14: pp. 184-185] 

Using another approach, this algorithm can be employed to schedule aperiodic 
(sporadic) tasks. Aperiodic tasks consist of a stream of jobs arriving at the processor 
according to some random process such as the Poisson process. In this case, there is 
no deterministic upper bound on the worst case processor utilization task even though 
each job of an aperiodic task has a bounded worst case e.xecution time. Thus, it is im- 
possible to guarantee that every job's deadline in an aperiodic task will be met. The 
concept behind dealing with aperiodic tasks is to reserve adequate processor time for 
each group of tasks so that fast average response time can be ensured. 

A simple way to realize this objective is to create a set of periodic tasks, each 
of which serves a group of aperiodic tasks. Each of these server periodic tasks will be 
run according to the basic piinciple of the rate monotonic algorithm. Associated with 
each server periodic task, there is a ready queue for associated aperiodic jobs. Each of 
these aperiodic jobs in the associated ready queue will be treated as if it is a periodic job 
of the server periodic task and dispatched accordingly. That is , if a periodic server has 
period P and nominal computation time C, then the associated aperiodic job can be ex- 
ecuted C time units in every period P at the priority level associated with period P, The 
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ration C/P represents the processor time allocated for associated aperiodic tasks. [Ref. 
14: p. 183] 

5. "NEXT-FIT-M" 

NEXT-FIT-M is better classified as a decomposition strategy than a scheduling 
algorithm. It was developed for use in conjunction with the rate-monotonic algorithm 
in a multi-processing environment. The requirement for this strategy is based on the fact 
that the rate-monotonic algorithm behaves poorly in multiprocessor systems if the rule 
is followed of not allowing a processor to idle when there is a task ready for execution. 

NEXT-FIT-M is based on the following assumptions: 

1. Tasks are time-critical and the requests of each task are periodic, with a constant 
interval betw'een tasks. 

2. Deadlines consist of runability constraints only, i.e. each request must be com- 
pleted before the next request of the of the same task occurs. 

3. The tasks are independent in that the requests of a task do not depend on the ini- 
tiation or the completion of the requests of other tasks. 

4. Computation time for the requests of a task is constant for the task. Computation 
time here refers to the time a processor takes to execute the request without inter- 
ruption. 

5. Task utilization is defined by two numbers, the computation time of tlie requcst(c), 
and the request period(t). The ratio c, t is called the utilization factor of the task. 
(Ref. 9: p.I94] 

In a multiprocessor environment, this utilization factor provides a means for 
decomposing tasks into classes. A class is defined for each available processor in the 
system, and tasks belonging to a given class are scheduled on the processor with the 
appropriate class designation. Task classes are created based on a range of utilization 
factors e.g. class A tasks have utilization fitetors between .4 and .1, class B tasks range 
between .2 and .4, etc.. Actual utilization ranges are established using a logarithmic 
scale derived from the formula — 1) as described by [Ref. 9: p. 195]. When de- 
composition and assignment of task classes to processors is complete, execution pro- 
ceeds on each processor according to the rate-monotonic algorithm. 

6. A TIME-DRIVEN SCHEDULING MODEL 

Another approach to scheduling is illustrated by the Time Driven Scheduling 
.Model and its two associated algorithms, BEValuel and BEValue2. (Ref. 10: pp. 
112-122] This model is based on a linear mathematical function. The concept of in- 
creasing or decreasing linearity is used to describe the precedence relationship among a 
set of processes. The input for the model is a set of preemptible processes P, resident in 



19 



a computer with a single shared memory and one or more processing elements. EacJi 
process P has a request time R, which is an arbitrary time at which P has been requested 
to be executed and a processing or computation time, C. For each P, a value function, 
V(t) is created where t is a time for which a value is to be determined and V defines the 
value to the system for cornpletmg P at time t. The nature of V is determined by which 
scheduling algorithm is used, BEValuel or BEValue2. 

These two algorithms take advantage of three value function and scheduling 
characteristics: 

1. Given a set of processes (ignoring deadlines) wdth known values for completing 
them, it can be shown that a schedule in which the process with the highest value 
density V/C. (in which V is its value and C is its processing time as previously de- 
scribed) is processed first will produce a total value at every point in time at least 
as high as any other schedule, (i.e. a Value Density Schedule) 

2. Given a set of processes with deadlines which can all be met (based on the sequence 
of the deadlines and the computation times of the processes), it can be shown that 
a schedule in which the process with the earliest deadline is scheduled first (i.e., an 
Earliest Deadline schedule) will always result in meeting all deadlines. 

3. Most value functions of interest have their highest value occuring immediately 
prior to the critical time. 

The BEValuel .Algorithm exclusively uses observation 1 above, and is therefore 
a simple greedy algorithm, scheduling first the process with the highest expected value 
density. It has been shown that this algorithm performs reasonably well in many cases 
in which the value function is a step function, or if the function is rapidly decreasing 
following the critical time, inspite of the fact it makes no use of critical time itself The 
critical time does, of course, enter the algorithm through the expected value computa- 
tion, which uses the value function and the assumed processing time distribution to 
compute an e.xpected value. It was also shown by experimental results, that this algo- 
rithm fails most notably in step function situations where processor loads are low or at 
an average level, and a number of processes with close deadlines are in the request set. 

The BEValue2 algorithm attempts to rectify this situation by the implementa- 
tion of the following modification. This algorithm starts with a deadline-ordered se- 
quence of available processes, which is then sequentially checked for its probability for 
overloading the processor. At any point in the sequence in which the overload proba- 
bility passes a preset threshold, the process prior to the overload condition with the 
lowest value density, will be removed from the sequence. This process is repeated until 
the overload probability reaches an acceptable level. Because of this modification, this 
algorithm tends to out perform BEValuel since it always meets deadlines as long as no 
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processing overload occurs. However, when an overload condition occurs and gradually 
worsens, performance of this algorithm is similar to BEValuel. [Ref 10: p.l 16] 

7. DYNAMIC SCHEDULING OF TASK GROUPS 

A more complex, yet extremely useful approach to process scheduling is de- 
scribed by [Ref 15: pp. 166-174|. This research examined the problem of dynamic 
scheduling for groups of tasks in distributed real-time systems. The scheduling algorithm 
developed to meet this requirement is broken down into several smaller algorithms, a 
pre-processing algorithm, a distributed scheduling algorithm, and a compression algo- 
rithm. 

The pre-processing algorithm divides processes into clusters and computes the 
required time to execute each cluster. Clusters are ordered into a precedence relationship 
based on these computations. This ordering is somewhat arbitrary and can be modified 
(through the the use of the compression algorithm) if necessary. Processes within a 
cluster are ordered according to real-time constraints by a method similar to that de- 
scribed by the earliest deadline approach. Based on this computation, this algorithm 
makes the decision whether or not there is enough processing time available to schedule 
a cluster of processes. If there is, a "dispatcher module" begins or enables the execution 
of the cluster. 

Once a cluster begins executing, due to precedence constraints, processes within 
the cluster must synchronize in real-time in order to conmiunicate with one another. 
When one process finishes executing, it sends an enabling message, as well as output 
data, to a successor process (the one which is next in the precedence ordering). A suc- 
cessor process can begin execution only after the enabling message from its predecessor 
has been received. Another module called the inter-task conununication handler, is in- 
voked each time a process finishes execution. This module evaluates incoming enabling 
messages and updates the number of finished predecessor processes when more than one 
is required for the execution of a particular successor task, and it sends enabling mes- 
sages to successor tasks. 

In the instance of a distributed system, the distributed scheduling algorithm is 
invoked when there is not enough processing time available to successfully execute a 
cluster. This algorithm attempts to find another location in the system for the cluster 
to be executed. 

When it appears that a cluster cannot be successfully executed at any location, 
the compression algorithm is invoked. Because the computed execution time for a 
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cluster is only an estimation, this algorithm is designed to compress the execution time 
for the entire cluster, or for individual processes when possible, within the cluster. [Ref. 
15: pp. 167-169, 173]. 

8. A RECEIVER-INITITATED SCHEDULING STRATEGY 

Another scheduling method is described in a comparison-oriented piece of re- 
search. Chang and Livny [Ref 16: pp. 175-180] examined Sender-Initiated and 
Receiver-Initiated scheduling strategies in a multiprocessor environment. The 
Receiver- Initiated approach is of primary interest and works in the following way. Upon 
the completion of a job (process) the load of the processor is examined to determine if 
it is underloaded. When the number of jobs left in the queue is smaller than some preset 
threshold, the processor is tagged as underloaded. When this condition occurs, the 
underloaded processor polls other processors in the system to offer "help" (i.e. processing 
resources). This technique was proven to be an eflective method for sharing and dis- 
tributing resources among processors in a multi-processing environment. The basic idea 
appears to be a reasonable approach for sharing resources among processes as well. 

9. APPLICATIONS OF THESE METHODS FOR THE CAPS SCHEDULERS 
The foregoing scheduling methods were described to provide background infor- 
mation on the development of scheduling techniques and also to provide a basis for the 
development of the CAPS dynamic scheduler. Some of the techniques are also useful 
for describing the operation of the CAPS static scheduler and how the static and dy- 
namic schedulers will interact in the execution support environment. 
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III. THE CAPS DYNAMIC SCHEDULER 



A. SCHEDULING FUNCTIONS 

Within the CAPS execution support system, the dynamic scheduler will perform se- 
veral functions. First, it will act as the "run-time" executive that invokes, or starts the 
static scheduler and buffer preloading procedures for the translator. Second, it will cre- 
ate and invoke a schedule for the non-time critical operators of the PSDL prototype, 
third it will handle exceptions (both defined and undefined types) for all of the the CAPS 
components, and fourth it will handle both hardware and operator interrupts that may 
occur during prototype execution. These functions are illustrated by Figure 4 on page 
24. 

The proposed operation of the dynamic scheduler is outlined by the hierarchal de- 
scription included as Appendix C. This design is based in part on Mok's "run-time 
scheduler" as described in [Ref. 12: pp. 5-17]. It provides the code for allocating re- 
sources in response to requests generated at run time, c.g. hardware or operator inter- 
rupts, and its scheduling decisions will not be dependent upon prior knowledge of future 
request times for processes to be executed. The specific functions it performs are de- 
scribed below. 

I. THE RUN-TIME EXECUTIVE FUNCTION 

At the start of prototype execution, the run-time executive function will invoke 
a procedure called PRELOADER for the translator. PRELOADER is a buffer initial- 
ization process required for implementation of PSDL data streams. The translator re- 
quires this process because buffers are regarded as "state machines" and must contain a 
certain value or be in a certain "state" at the start of prototype execution. 

The static scheduler decomposes the prototype into a set of time critical and 
non-time critical operators. The result of this decomposition are files or "queues" of 
operators which are the input for the static schedule or the dynamic schedule. The 
run-time executive function will also invoke (start) the execution of the static schedule 
once it's created. 

The schedule for time critical operators is based on the precedence relationships 
among the operators, and on the prototype's real-time constraints. The static scheduler 
creates a schedule that will ensure that both of these requirements arc met. One of the 
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Figure 4. DYNAMIC SCHEDULER FUNCTIONS 



24 



sclieduling approaches it uses to accomplish this is a blocking strategy similar to the 
method employed by Mok's Kernelized Monitor Model. 

In the formulation of the static schedule, the static scheduler assumes worst case 
rather than average case processor utilization for meeting a given operator's processing 
requirements. The scheduling blocks will also contain periods of time between operators 
in which nothing is scheduled in order to ensure tliat precedence relationships are 
maintained (i.e. data flow requirements are met). These two conditions result in idle 
processing time that can be used by the dynamic scheduler to schedule and execute the 
prototype's non-time critical operators. The resulting spare processing capability will 
therefore occur unpredictably as shown by Figure 5 on page 26. It is then up to the 
dynamic scheduler to schedule non-time critical processes into these idle areas of the 
static schedule. This idea is similar to the "swapping" methodology employed by the 
"ED-PP" algorithm, and the "time-division multiplexing" approach within the rate 
monotonic algorithm. 

2. THE CREATE NON-TIME CRITICAL OPERATOR SCHEDULE 
FUNCTION 

When idle processing time is available for use by the dynamic scheduler, the 
steps illustrated by Figure 6 on page 27 will take place. The static scheduler will attempt 
to "rendezvous" with the dynamic scheduler in order to indicate or "send the message" 
that processing time (a "time slice") is available. This process is based on the "receiver- 
initiated" (poll-when-idle) strategy, and on the concepts of "inter-task communication" 
and "dispatcher" modules as described in the discussion of dynamic scheduling algo- 
rithms for distributed systems. 

The dynamic scheduler must then determine (i.e. perform a compare operation) 
if there is enough time available in the time slice to execute a non-time critical process 
before the next scheduled start time of a time-critical scheduling block. This compare 
operation is analogous to an operation performed by the BEValue2 algorithm of the 
time-driven scheduling model. Recall that this algorithm makes a determination as to 
whether or not a given process will overload the processor. Similarly, the dynamic 
scheduler should determine whether or not a non-time critical process can be successfully 
executed within a given amount of time. If this is not possible, the process won't be 
scheduled. When there is enough time available, operators will be scheduled using one 
of the basic principles of the rate-monotonic algorithm. That is, an operator with the 
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Figure 5. STATIC SCHEDULER BLOCKING METHOD 

shortest execution time will be considered to have the highest priority and will be 
scheduled for execution first. 

This "priority" assignment is an arbitrary' one since the processes to be executed 
are not time critical. The logic of this approach is simply to schedule as many non-time 
critical processes as possible into a "block" of idle time and it is based on the following 
assumptions; 

1. Employment of a more complex scheme such as the creation of a "value density 
schedule", is unnecessary' and would not effectively contribute to allotment of 
processing resources among the non-time critical processes. 

2. Processes are independent of one another (i.e. there are no precedence relationships 
among the operators). 

3. An execution time must be assigned to each of the operators during the specifica- 
tion phase of prototype development. Tlie assigned execution time should not be 
confused with a "timing constraint", it is only meant to provide an estimate of the 
resources required for the execution of a non-time critical process. 
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Figure 6. CREATION AND EXECUTION OF THE DYNAMIC SCHEDULE 

4. Non-time critical processes will be sequenced in the "operator queue" based on a 
"shortest first" scheme. This sequencing will be performed by the static scheduler 
during the prototype decomposition operation. 

For as long as time remains in an unused portion of the static schedule, the 
dynamic scheduler can schedule non-time critical processes for execution based on the 
preceding assumptions. When there is not enough time available to schedule the oper- 
ator at the top of the queue (the operator with the shortest processing requirement), the 
dynamic scheduler will go into a "wait" state and allow the processor to remain idle until 
the start of the next static scheduling period. Allowing idle time in this instance is based 
on the idea of a "forbidden region" in the Kernelized Monitor .Model. This forbidden 
region is necessary in order to ensure that a future deadline of the static schedule can 
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be met. Allowing this idle time when using a rate monotoiiic approach also makes sense 
from a performance standpoint since utilization related research has indicated that 
processing efficiency tends to decline for processor loads above In 2 (approximately 
70%). 

Even though a "compare" operation is performed to determine whether or not 
an operator can be completed within a given amount of time, the case may arise when 
a non-time critical process may exceed this amount of time. This cannot be allowed to 
occur since it would interfere with the static schedule and in effect, meeting the require- 
ments of the system's real-time constraints. Therefore, execution of the non-time critical 
process must be preempted by some type of monitor. 

The monitoring operation created to do this should track the status of an exe- 
cuting process relative to a system clock, and will terminate (preempt) a process in order 
for the next scheduling block within the static schedule to begin. When a process is 
terminated, it will be returned to the proper sequence position in the operator queue so 
that it can be rescheduled at another time. This monitoring process will also perforin 
status monitoring with regard to completion of an operator i.e. it will "notify" the 
compare operation that the execution of a process is complete so that an attempt can 
be made to schedule another process. Finally, the monitor will call exception or inter- 
rupt handling procedures when the execution of a non-time critical process results in one 
of these two conditions. 

3. THE TERMINATE PROTOTYPE FUNCTION 

When exceptions occur as a result of processing performed by any of the three 
CAPS components, the terminate prototype function will be called. This function will 
perform the operations necessary to terminate the execution of the entire prototype, c.g. 
terminate whatever processes are executing at the time the exception occurs, and notify 
the CAPS user that an exception of a certain type has occured. 

4, THE HANDLE INTERRUPTS FUNCTION 

Two types of interrupts can occur while a prototype is executing, an operator 
interrupt and a hardware interrupt. Depending upon the nature of the interrupt, this 
function will call the terminate prototype function or it will initiate some other appro- 
priate interrupt handling procedure. For example, in the instance of a hardware inter- 
rupt, instructions to go to a particular hardware address could be executed. 
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B. THE USE OF ADA 

The dynamic scheduler will be implemented in Ada® as previously described. Ap- 
pendix D provides a "skeleton" program based on the Ada® language in order to show 
some of the features of the language which are relevant for this implementation. For 
example, it demonstrates the use of an Ada® procedure. Recall that an Ada® procedure 
is a fundamental programming unit that encapsulates a series of statements. 

This program also demonstrates the use of a task. A task in Ada® is based on the 
concept of communicating sequential processes. Tasks can be viewed as independent, 
concurrent operations that communicate with one another by passing "messages" [Ref. 
5: pp. 68, 70]. This feature is particularly important to the CAPS execution support 
system as mentioned earlier because it provides the means for communication among 
each of the three CAPS components. 

Another feature of the language included in this program is the instantiation of the 
generic package CALENDAR. CALENDAR has a predefined function, CLOCK that 
returns the time of day and exports a data type of time. This package provides a simple 
yet effective means for monitoring the execution time of an operator. 

One other aspect of Ada® illustrated in Appendix D is an exception handling pro- 
cedure. The Ada® language contains several predefined exceptions, and it also provides 
a user with the ability to define exceptions for a given application. For the CAPS, these 
user-defined exceptions will be be the predefined PSDL exceptions (e.g. 
FULL_BUFFER, EMPTY_BUFFER). 

An exception is handled within the program unit where it is created (via a raise 
statement), or it can be sent (propagated) to another unit for handling. Since the dy- 
namic scheduler is considered to be the run-time executive for the CAPS execution sup- 
port system, it makes sense from an elficiency standpoint to handle exceptions at this 
"central" location within the execution environment. 

The "centralization of control" logic also makes sense for the the handling of inter- 
rupts. Although not shown by the skeleton program, interrupt handling procedures can 
include an Ada® representation clause which allows the use of machine-dependent facil- 
ities. For example, an Ada® representation clause of the form "for FAIL use at 
16#1FE#" as illustrated by [Ref 5: p. 308] can be used. The he.xadecimal number 
16slFEff represents some hardware or vector address. 

One last language feature which should be mentioned, is a possible "file" structure 
for storing the non-time critical operators. Recall that this file (the "operator queue") 
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is one of the results of the prototype decomposition performed by the static sclieduler. 
Several different structures could be used depending upon which would provide the most 
effective means for performing input and output operations on processes during dynamic 
scheduling. One structure which is often used in ,A.da® to hold sorted data is a binary 
tree as illustrated by [Ref. 17: p. 150]. Other file structures which could be used include 
a linked list or a data stack. Implementation of any of these would allow the dynamic 
scheduler to perform the input/output operations required by its design. 
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IV. SUMMARY 



A. THE QUESTIONS ANSWERED 

This study attempted to meet two objectives: 

1. Conceptual development of a dynamic scheduling component for the computer- 
aided design system CAPS 

2. Interface of the dynamic scheduling component with the other two components of 
the CAPS execution support system 

The focus on these objectives has resulted in the conceptual development of a four 
function dynamic scheduler. This design as outlined by Appendix C, demonstrates how 
the dynamic scheduler will interact with the translator and the static scheduler compo- 
nents within the CAPS execution support environment. Further, the scheduling ap- 
proach proposed for the scheduling of a prototype's non-time critical provides a viable 
alternative for making effective use of idle processing resources that occur as a result of 
ensuring that a system's real-time constraints are met. 

B. THE PROBLEMS THAT REMAIN 

Future research for the CAPS dynamic scheduling problem needs to address several 
areas. An area of primary importance is a more detailed development of the conceptual 
design, including an examination of its feasibility given the assumptions its based on. 
Special attention should be placed on developing a more detailed description of the op- 
erations required for the "Create Non-time Critical Operator Schedule" function. Once 
this process is complete, the Ada® coding required to implement the dynamic scheduling 
functions can proceed. 

Another area which needs to be addressed is the development of a "debugger" 
function for the dynamic scheduler as proposed by [Ref 18] and [Ref 2: p. 9j. The 
purpose of the debugger is to collect statistics on prototype behavior and to accept 
control of prototype execution when a PSDL exception occurs. (Recall that the initial 
dynamic design merely terminates prototype execution). The addition of this function 
would enhance, and at the same time, possibly reduce the number of iterative phases 
required during prototype development because of the additional control and informa- 
tion it provides to the designer. 

The debugging function can be fairly conventional. For example, the ability to at- 
tach breakpoints to operators, which can be conditional with respect to a I'SDL predi- 



31 



cate (an "if' condition) could be included. Selected inputs or outputs of an operator 
should be traceable, resulting in a display of the values and their associated arrival or 
departure times. Commands for inserting and deleting values in data streams should 
also be provided. 

The facilities for gathering statistics should include commands for monitoring both 
frequencies and timing information. Frequency statistics include the number of values 
that pass down a data stream, the number of times an e.xception occurs, etc. Timing 
statistics include minimum, average, standard deviation, and maximum times for the 
execution, response, or intervals between firings of an operator. These statistics are in- 
tended primarily for feasibility and performance studies. [Ref. 19: pp. 10 -13J 

C. CAPS: AN EFFECTIVE DEVELOPMENT ALTERNATIVE 

An example of an elTort that would derive substantial benefit from the use of CAPS 
is the software development required for implementation of the Defense Switched Net- 
work (DSN). The implementation strategy that will be employed requires components 
and features to be adopted gradually, beginning with an initial capability based on to- 
day's voice network [Ref. 20: p. 11]. 

The DSN is the future Command and Control (C2) telecoimnunications network for 
the U.S. strategic armed forces. It is being designed to provide rapid, endurable, and 
economical teleconununications services to both high and low priority users. High pri- 
ority users require immediate (i.e. real-time) service under the most dilficult mission 
stress conditions. Low priority users require service for performing operational support 
activities such as logistics and personnel related functions which are not subject to the 
same type of real-time constraints. In order to meet these requirements, the network is 
planned to include more than 200 U.S. Government-owned conmuinications switches in 
Europe and more than 60 U.S. Government-owned switches in the Pacific, as well as 
commercially leased switching and transmission services in the Western-Hemisphere and 
Hawaii. [Ref 20: p. 6] 

Comprehensive computer support that is highly reliable from both a security and a 
survivability standpoint, will be required to maintain control of this vast network. This 
computer support will assist in performing these network functions: 

1. monitoring and surveillance to detect performance abnonnalilics automatically 

2. implementing real-time controls that prevent switch or network congestion 

3. analyzing trallie data to permit continuous optimal operation of the network 
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Computer aids that minimize personnel requirements will also be employed-locally 
and from remote locations--in administration, operations, maintenance, and network 
management of network elements. [Ref. 20: p. 6] 

This diverse set of requirements illustrates why this development effort would be 
significantly enhanced by using CAPS, its prototyping methodology, and PSDL. This 
is especially true if the computer support systems are developed using Ada® as currently 
planned. 

D. CONCLUSION 

A primary advantage of CAPS for system development is that PSDL use for con- 
struction of an executable prototype would be much easier and simpler than direct use 
of Ada®. Additionally, executing a prototype (or prototypes) that demonstrates the 
functioning and interaction of modules within a complicated embedded system like the 
DSN, would significantly increase the confidence that the system can be built as 
planned. Using a prototype would also improve cost estimates since the cost of the in- 
tended system is generally proportional to the cost of a rapid prototype. [Ref 19: p. 12] 
The conceptual development of the CAPS dynamic scheduler represents a significant 
step forward in meeting the demand for rapid development of reliable software for large 
real-time computer systems. Additionally, the proposed "shortest first" scheduling al- 
gorithm used by the dynamic scheduler could be effective for scheduling non-time critical 
processes in other real-time environments as well. This scheduling approach could prove 
to be an effective way for utilizing idle processing resources which are often wasted in 
large real-time systems. 
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APPENDIX A. A PSDL PROTOTYPE 



This is an example of a PSDL prototype as it appears in [Ref. 4: pp. 27-40]. It was 
developed to model a simple system for treating brain tumors using hyperthermia. 



OPERATOR brain_tuinor_treatment_syste[n 
SPECIFICATION 

INPUT patient_chart: medical_history , 

treatment_switch: boolean 

OUTPUT treatment_finished: boolean 

STATES temperature: real 

INITIALLY 37.0 
DESCRIPTION 

{The brain tumor treatment system kills tumor cells 
by means of hyperthermia induced by microwaves. 

END 

IMPLEMENTATION 

GRAPH 



100 




DATA STREAM treatment_power: real 

CONTROL CONSTRAINTS 
OPERATOR hyperthermia_system 
PERIOD 200 BY REQUIREMEfiTS shutdown 
OPERATOR simulated_patient 
PERIOD 200 

DESCRIPTION (paraphrased output} 

END 



TYPE medical_history 
SPECIFICATION 

OPERATOR get_tumor_diameter 
SPECIFICATION 

INPUTS patient_chart: medical_history, 

tumor_location: string 
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OUTPUTS diameter: real 

EXCEPTIONS no_tumor 
MAXIMUM EXECUTION TIME 5 ms 
DESCRIPTION 

{Returns the diameter of the tumor at a given location, 
produces an exception if no tumor at that location. 

END 



KEYWORDS patient_charts , medical_records , treatment records, 
lab records 

DESCRIPTION 

(The medical history contains all of the disease and 
treatment information for one patient. The operations 
for adding and retrieving information not needed by 
the hyperthermia system are not shown here. 

END 

IMPLEMENTATION 

tuple (tumor_desc: map-from: string, to: real{, ... } 

OPERATOR get_tumor_diameter 
IMPLEMENTATION 
GRAPH 



t 




DATA STREAM td: tumor_descr 

CONTROL CONSTRAINTS 
OPERATOR map. fetch 

EXCEPTION no_tumor IF not(map. has(tumor_location, td)) 

END 



END 



OPERATOR hyperthermia_systera 
SPECIFICATION 

INPUT temperature: real, patient_chart: medical_history , 

treatment_switch: boolean 

OUTPUT treatment_power: real, treatment_finished: boolean 

MAXIMUM EXECUTION TIME 100 ms 
BY REQUIREMENTS temperature_tolerance 
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MAXIMUM RESPONSE TIME 300 ms 

BY REQUIREMENTS shutdown 
KEYWORDS raedical_equipment , temperature_control , 
hyperthermia, brain_tumors 
DESCRIPTION 

{After the doctor turns on the treatment switch, the 
hyperthermia system reads the patient* s medical record 
and turns on the microwave generator to heat the tumor 
in the patient* s brain. The system controls the power 
level to maintain the hyperthermia temperature of 
42.5 degrees C. for 45 minutes to kill the tumor cells. 
When the treatment is over, the system turns off the 
power and notifies the doctor. 

} 

END 

IMPLEMENTATION 

GRAPH 



QO 




DATA STREAM estimated_power: real 

TIMER treatment_t ime 
CONTROL CONSTRAINTS 
OPERATOR start_up 
TRIGGERED IF temperature < 42.4 
BY REQUIREMENTS raaxiraum_teraperature 
STOP TIMER treatment_time 

RESET TIMER treatment_t ime IF temperature <= 37. 0 

OPERATOR maintain 
TRIGGERED IF temperature >= 42. 4 
BY REQUIREMENTS raaximum_temperature 
START TIMER treatment_time 

BY REQUIREMENTS treatment_time, temperature_tolerance 
OUTPUT treatment_f inished IF treatment^time >= 45 min 
BY REQUIREMENTS treatment_t ime 
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END 



OPERATOR start_up 
SPECIFICATION 

INPUT paCient_chart: medical_history , temperature: real 

OUTPUT estimated_power: real, treatment_£inished: boolean 

BY REQUIREMENTS startup_time 
MAXIMUM EXECUTION TIME 90 ms 
BY REQUIREMENTS temperature_tolerance 
DESCRIPTION 

{Extracts the tumor diameter from the medical history and 
uses it to calculate the maximum safe treatment power. 
Estimated power is zero if no tumor is present. The 
treatment finished is true only if no tumor is present. 

END 

IMPLEMENTATION Ada start.up 
END 



OPERATOR maintain 
SPECIFICATION 
INPUT temperature: real 

OUPUT estimated_power: real, treatment_f inished: boolean 

MAXIMUM EXECUTION TIME 90 ms 
BY REQUIREMENTS temperature_tolerance 
DESCRIPTION 

( The power is controlled to keep the power between 42.4 
and 42. 6 degrees C. 

} 

END 

IMPLEMENTATION Ada maintain 
END 



OPERATOR safety_control 
SPECIFICATION 

INPUT treatment_switch, treatment_f inished: boolean 

estimated_power; real 
OUTPUT treatment_power: real 

BY REQUIREMENTS shutdown 
MAXIMUM EXECUTION TIME 10 ms 
BY REQUIREMENTS temperature_tolerance 
DESCRIPTION 

(The treatment power is equal to the estimated power 
if the treatment switch is true and treatment finished 
is false. Otherwise the treatment power is zero. 

END 

IMPLEMENTATION Ada start_up 
END 
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APPENDIX B. PSDL GRAMMAR SUMMARY 



This is a sunmian'^ of PSDL grammar and language conventions as initially de- 
scribed in [Ref. 1: pp. 54-56] and further refined by [Ref. 6]. Several conventions are 
used for symbology in the grammar. [ Square Braces ] indicate optional items. ( Curly 
Braces } indicate items which ntay appear zero or more times. Bold face type indicates 
a named terminal symbol which must appear in the program listing the programmer 
writes. "Double quotes" indicate character literals which must appear in the program 
listing. The "|" vertical bar indicates an exclusive-or selection. In this case the pro- 
grammer selects one and only one of the items separated by the vertical bar. 

.As an example, the token timing_info is one of six mutually exclusive possibilities 
which may define the attribute token. The attribute token may appear zero or more 
times to define the interface token, which is a required attribute of the operator_spec 
token. Timing_info, if selected for attribute, may be empty, or it may contain one or 
more of the optional tokens allowed to define timing_info. Each of these tokens may 
appear no more than one time for a given instance of timing_info. 



psdl = ( component } 

component = [ data_type 

I operator 

data_type = type id type_spec type_impl 



operator = operator id operator_spcc operator_impl 

type_spec = specification [type_decl] (op_spcc_list) [functionality] end 

op_spec_list = operator id operator_spcc 

operator_spec = specification interface [functionality] end 

interface = {attribute [reqmts_tracc]} 



attribute = 



gencric_param 

input 

output 

states 

exceptions 

timing_info 



gcneric_param = generic type_dccl 
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input = input type_decl 
output = output type_ded 

states = states type_decl initially expression_list 
exceptions = exception idjist 
id_list = id ( id } 

timing_info = [maximum execution time time] 

[minimum calling period time[ 

[maximum response time time] 

time = number [unit] 

unit = I microsec | ms | sec | min | hours 

reqmts_trace = by requirements idjist 

functionality = [keywords] [informal_desc| [formal_desc] 

keywords = keywords idjist 

informal_desc = description text "}" 

formaI_desc = axioms text 

type_impl = | implementation Ada id 

I implementation type_name { opjmpljist } end 

opjmpljist = operator id operatorjmpl 

operator_impl = | implementation Ada id 

I implementation psdljmpl 

psdljmpl = data_now_diagram 
[streams] 

[timers] 

[control_constraints[ 

[informal_desc] 

end 

data_flow_diagram = graph [ link } 
link = id opid id 

opid = id [ time] 
streams = data_stream type_decl 

type_decl = id_list type_name { " " id_list type_name } 

type_name = | id 

I id "[" typc_decl "[" 

timers = timer idjist 

control_constraints = control constraints ( constraint } 
constraint = operator id 
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(triggered [trigger] [ "if predicate] [reqmts_trace] ] 
[period time [reqmts_trace] ] 

[finish uitliin time [reqmts_trace] ] 

{output id_list if predicate [reqmts_trace] } 
(exception id [if predicate] [reqmts_trace] } 
(timer_op id [if predicate] [reqmts_trace] } 



timer_op = 


1 start ] stop 1 


read j 


reset 


trigger = 


1 by all id_lisl 








1 by some id_list 




predicate = 


■ 1 not predicate 








j predicate and 


predicate 




] predicate or predicate 




] expressionjist 
1 id id_list 






expression_ 


list = expression 




expression} 


expression 


= 1 number 








1 constant 

1 itl 

1 type_name 


id 


"(" expression_list ") 
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APPENDIX C. DYNAMIC SCHEDULER FUNCTIONS 



1. 0 Run-Time Executive 

1. 1 Invoke Translator Preloader Procedure 

1. 2 Invoke Static Scheduler 

2. 0 Create Non-Time Critical Operator Schedule 

2. 1 Compare Time Slice to Operator Queue Time Requirement 

2. 1. 1 Find top of queue (operator with shortest 
time requirement) 

2.1.2 Subtract operator time requirement from time slice 

2.1.3 When result of subtraction > 0, send time 
available message to execute operator function 

2.1.4 When result of subtraction < 0, let processor 
idle until start of next static schedule 
requirement 

2. 2 Schedule Operator 

2. 2. 1 Schedule available operator from operator 
queue for execution 

2. 2. 2 Send completion message to monitor 

2. 2. 3 Send exception message to monitor 

2.2.4 Send hardware/interrupt message to monitor 

2. 3 Monitor Process 

2. 3. 1 Monitor execution time of operators 

2. 3. 2 Terminate operator if available 
processing time is exceeded 

2.3.3 When operator completes execution, 
send message to compare operation 
to see if more execution time is 
available 

2.3.4 When exception occurs during dynamic 
schedule processing, call terminate 
prototype function 

2.3.5 When interrupt occurs during dynamic 
schedule processing, call handle 
interrupts function 

3. 0 Terminate Prototype 

3.1 Terminate Translator 

3. 2 Terminate Static Scheduler 

3. 3 Terminate Dynamic Scheduler 

4. 0 Handle Interrupts 

4. 1 Send terminate request to terminate prototype 

4. 2 Send non-terminatable request to appropriate 
location 
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APPENDIX D. PSEUDO-CODE FOR AN ADA PROGRAM 



This pseudo-code illustrates some useful features of the Ada® programming lan- 
guage (Ada® is a registered trademark of the United States Government, Ada Joint 
Programming Office). A detailed description of how these features can be implemented 
in an Ada® program appears in [Ref. 5] 



--Two hyphens indicate the start of a comment in the Ada language. 
--Four hyphens within this pseudo-code are used to enhance 
--readability and to indicate the absence of formal 
--parameters, statements, or other features of the language 
--that are required by an actual program 



with OPERATOR^QUEUE; --the operator queue of 

--non-time critical processes 
--will be created by the 
--static scheduler 



with CALENDAR; --the Ada language definition 

--includes the package CALENDAR 
--with a predefined function, 
--CLOCK that returns the time 
--of day and exports a data type 
--of time 



procedure DYNAMIC^SCHEDULER is 



declare 



FULL^BUFFER: 

EMPTY.BUFFER: 

OVER.TIME: 

PSDL^EXCEPTION: 



exception; --when an exception is 
exception; --raised within an Ada 
exception; --program unit, it is 
exception; --propogated to a level 
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--where it can be handled 



type READY is text; 
type SCHEDULE is text; 
type TIME_SLICE is text; 



--the text types indicate the 
--different messages exchanged 
--during a rendezvous 



PRELOAD 

SCHEDULE 

IDLE 



READY; 

CREATED; 

TIME_SLICE; 



procedure PRELOADER; --PRELOADER will be some actions 

--that will invoke buffer 
--initialization procedures for the 
--translator 



procedure START; --START will consist of some actions 

--to start the execution of the 
--static schedule 



procedure CREATE_SCHEDULE is --the procedure that will 

--create a schedule for 
--the non-time critical 
--operators 



use CALENDAR; 
use OPERATOR_QUEUE; 



TIME, OPERATOR_TIME_REQUIREMENT ; TIME_SLICE; 



begin 



--COMPARE OPERATION 
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--find top of 0PERAT0R_QUEUE (operator with shortest 
--time requirement) 

--select this operator and compare its execution 
--time with TIME_SLICE in order to determine 
--if enough time is available to 
--execute this non-time critical process 

--while enough time is available, in a given 
--TIME_SLICE , schedule processes for execution 

--else let the processor idle till start 
--of next static scheduling block 



MONITOR^PROCESS --implement a process to monitor 
--status of executing non-time 
--critical operators (time, completion, etc.) 
--using the generic package CALENDAR 



end CREATE^SCIIEDULE; 



task RUN_TIME_EXECUTIVE is --an Ada task is an effective 

--method for implementing the 
--the run-time executive function 
--because it provides a means for 
--communication among the three 
--execution support system commponents 

--entry and accept provide the 
--means for *^two way” 

--communications among the three 
--execution support system components 

entry TRANSLATOR (PRELOAD : in READY); 

--the communications path from 
--the dynamic scheduler 
--to the translator which will be 
--used to invoke the buffer 
--preloader procedure 

entry STATIC^SCHEDULER (SCHEDULE : in CREATED); 
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--the communications path between 
--the dynamic scheduler and the 
--static scheduler which will be 
--used to invoke (start) the 
--execution of the static schedule 



entry IDLE.TIME (IDLE : in TIME_SLICE); 

--the communications path between 
--the dynamic scheduler and the 
--static scheduler which will be 
--used to indicate to the dynamic 
--scheduler when idle time is 
--available 

end; 



task body RUN.TIME_EXECUTIVE is 



begin 



accept TRANSLATOR (PRELOAD : in READY) do PRELOADER; 

--PRELOADER will be some actions that 
--will invoke buffer initialization 
--instructions 



accept STATIC_SCIIEDULER (SCHEDULE : in CREATED) do START; 

--START will consist of some actions 
--to start the execution of the static 
--schedule 



accept IDLE.TIME (IDLE : in TIME^SLICE) do CREATE.SCHEDULE; 

--when idle time is available, the 
--dynamic scheduler can schedule 
--non-time critical processes for 
--execution during a given 
-- time slice 
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end RUN_TIME_EXECUTIVE; 



begin 



RUN_TIME_EXECUTIVE. TRANSLATOR (PRELOADER); 
RUN_TIME_EXECUTIVE. STATIC_SCHEDULER (START); 
RUN_TIME_EXECUTIVE. IDLE_TIME (CREATE_SCHEDULE); 



--when an exception occurs, the generic procedure TEXT_IO 
--and an application specific procedure such as PUT_LINE 
--can be used indicate to the CAPS user what the nature 
--of the exception is 



exception 

when FULL_BUFFER=> 

TEXT_IO. PUT_LINE ("An attempt was made to 

update a full buffer"); 
TERM INATE_PROTOTYPE ; 

--using the Ada generic package TEXT_IO, 
--and a user written procedure PUT_LINE, 
--a message as shown will appear on the 
--user's screen and prototype execution 
--will be terminated when an exception is 
--raised. 

end; 



exception 

when EMPTY_BUFFER=> 

TEXT_IO. PUT_LINE ("An attempt was made to 

read data from an empty 
buffer"); 

TERMINATE_PROTOTYPE; 
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end; 



exception 

when OVER_TIME=> 

TEXT_IO. PUT.LINE ("A PSDL operator has 

exceeded maximum 
execution time”); 
TERM I NATE^PROTOTYPE ; 



end; 



exceptioi 

when PSDL_EXCEPTION=> 

TEXT^IO. PUT.LINE (”An undefined PSDL 

exception 
has occurred”); 
TERM I NATE.PROTOTYPE ; 



end; 



end DYNAMIC_SCHEDULER; 
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